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ABSTRACT 

Due to the émergence of the semantic Web and the increas- 
ing need to formalize human knowledge, ontologie engineer- 
ing is now an important activity. But is this activity very 
différent from other ones like software engineering, for ex- 
ample ? 

In this paper, we investigate analogies between ontologies 
on one hand, types, objects and data bases on the other one, 
taking into account the notion of évolution of an ontology. 
We represent a unique ontology using différent paradigms, 
and observe that the distance between thèse différent con- 
cepts is small. We deduce from this constatation that ontolo- 
gies and more specifically ontology description languages can 
take advantage of beeing fertilizated with some other com- 
puter science domains and inherit important characteristics 
as modularity, for example. 

Catégories and Subject Descriptors 

1.2.4 [Artiflcial Intelligence]: Knowledge Représentation 
Formalisms and Methods; H. 3. 4 [Information Storage and 
Retrieval]: Systems and Software 

General Terms 

Design, Languages 

Keywords 

Ontology engineering, Knowledge modeling, Semantic Web 

1. INTRODUCTION 

Les ontologies sont une manière de représenter de façon 
formelle la connaissance. Un des buts principaux des on- 
tologies est d'être partagées entre un groupe de personnes 
pour fixer une terminologie et les relations entre concepts, 
aussi bien pour une utilisation humaine que pour une ma- 
chine |14] . Ces ontologies sont utilisées par des annotations 
sémantiques qui sont la base du Web sémantique [51 [5] . 



De plus en plus d'ontologies sont maintenant publiées di- 
rectement sur le Web. D'abord "légères" (comrtant les ter- 
mes d'un vocabulaire et des relations entre ces termes) elles 
laissent maintenant la place à des ontologies plus lourdes 
qui comportent aussi des règles et des possibilités de raison- 
nement logique, et à l'élaboration de méta-modèles (Ontol- 
ogy définition metamodel ODM) en rapprochant les visions 
logiques (DL), structurelle (OWL) et génie logiciel (ULM). 

Cette complexité du développement des ontologies a amené 
à parler de génie ontologique comme on parle de génie logi- 
ciel. Ces deux diciplines ont pour l'instant peu d'interactions, 
et pourtant elles ont de nombreux points communs. De 
même que les objets manipulés par un programmes peu- 
vent devoir (pour des raisons de performances par exem- 
ple) s'incarner dans des structures de données différentes, 
une ontologie, qui est le plus souvent décrite en utilisant 
OWL, peut devoir être représentée de multiples façons suiv- 
ant l'utilisation qu'on veut en faire : systèmes de types, 
bases de données, langages objets. Les possibilités d'expres- 
sion de ces différents paradigmes étant différentes, les con- 
fronter devrait permettre d'importer dans le monde des on- 
tologies de nouveaux concepts. Un autre point commun 
entre ontologies et logiciels est la notion d'évolution et de 
conséquences d'une évolution. 

Nous introduisons d'abord OWL et un extrait d'ontologie 
représenté dans ce langage, puis un état de l'art sur les trans- 
formations possibles dans les divers paradigmes évoqués. 
Nous proposons alors une traduction de notre exemple dans 
chacun d'eux. Nous soulignons les spécificités apportées et 
nous allons plus loin que la simple traduction d'un exemple 
statique en examinant des cas d'évolution de l'ontologie ; au 
niveau base de données ou systèmes de types et d'objets, 
nous montrons que l'on peut repérer les instances qui devi- 
ennent incohérentes avec la nouvelle structure, et que, grâce 
à la trace du changement de l'ontologie OWL, nous pouvons 
assurer la robustesse de notre multi-représentation en faisant 
évoluer les traductions. Nous terminons en résumant les ap- 
ports et limites de chaque représentation et en envisageant 
une synthèse des points les plus positifs. 
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2. OWL ET UN EXTRAIT D'ONTOLOGIE 

Le langage OWL (Web Ontology Language) est le lan- 
gage de marquage sémantique standard du web. OWL étend 
RDF et RDFS pour mieux décrire les propriétés et les classes 
(classes disjointes et connecteurs logiques entre elles, carac- 
téristiques globales des propriétés comme la réflexivité. . . ). 
Il admet, à côté de sa syntaxe abstraite, une syntaxe con- 
crète en RDF/XML (que l'on peut abréger en triplets N3 
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Figure 1: Classes 

comme nous le ferons dnas la suite). 

OWL permet de raisonner et d'établir des inférences. Le 
contenu principal d'une ontologie OWL tient dans ses ax- 
iomes qui fournissent des informations concernant les classes 
et les propriétés et dans ses faits qui fournissent des infor- 
mations concernant les individus. 

Notre illustration est un extrait d'ontologie inspiré de [2Ô] . 
La figure 1 présente les classes et la figure 2 les propriétés 
sous Protégé/OWL [TS]. 

En suivant une méthodologie classique pour construire 
une ontologie, on place d'abord des classes primitives en 
hiérarchie simple (ronds gris de la figure 1). Voici un extrait 
en OWL ou N3 : 

:MEinager rdf s : subClassOf :Person . 

Les propriétés sont indépendantes des classes et hiérachi- 
sées (figure 2). Leur cible est un type standard ou une classe 
(propriété objet) . Les propriétés objet sont supposées multi- 
valuées avec, éventuellement, un domaine et un co-domaine 
cible (ou range) comme dans : 

: studyAmong a rdf : Property . 

: studyAmong rdfs: domain : Trainee; 

rdf s : range : Department . 

Une originalité de la démarche ontologique qui relie les 
instances à des classes a posteriori et permet de donner une 
propriété quelconque à un individu (à charge pour un raison- 
neur d'en évaluer les conséquences) est à prendre en compte. 
Dans notre exemple, choisir Trainee pour domaine de la pro- 
priété StudyAmong amènera à proposer tout individu ayant 
la propriété studyAmong comme une instance de Trainee. 

Les aspects globaux d'une propriété (fonctionnalité, tran- 
sitivité) s'expriment aussi grâce à OWL ; ici work et manage 
sont fonctionnelles. 

On enrichit ensuite la description précédente en intro- 
duisant des classes définies, notamment les restrictions. Une 
restriction est une classe anonyme demandant que ses in- 
stances satisfassent à une restriction donnée (cardinalité, 
existence d'une valeur cible de classe donnée) sur une pro- 
priété. Par exemple on peut imposer que studyAmong ait au 
moins une valeur cible de classe Computer : 
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Figure 2: Propriétés 

[ a owl : Restriction; owl : onProperty : studyAmong 

; owl : someValuesFrom : Computer]. 

On peut alors préciser la classe ComputerTrainee sous- 
classe de Trainee en lui imposant d'être sous-classe de la 
classe anonyme précédente. En fait, c'est même une classe 
équivalente à l'intersection des sur-classes (classe définie, 
dite complète en OWL). 

Le Web sémantique décentralise les instances (faits, ABoxes) 
conformes au schéma (a:xiomes, TBoxes) d'une ontologie. Ce 
sont des sources de données RDF ou des annotations d'une 
page Web. Dans notre exemple : 

:rl a :Person. 

:r2 a :PhdStudent. 

: r3 a : Manager . 

: r4 a : Manager . 

:r5 a : Researcher. 

:r6 a : Researcher. 

:r7 a : Director. 

:r8 a : Director. 

:vl a : Department. 

:v8 a : Department 

:rl :work :vl. 

:r2 :work :v2. 

:r3 :work :v3. 

: r4 : manage 

: v4 . : r5 

: work : v5 . 

:r6 : manage 

: v6 . : r7 

: work : v7 . 

:r8 : manage :v8. 

3. ÉVOLUTION DES ONTOLOGIES 

Tout comme un programme, une ontologie est une entité 
vivante. Il y a bien sur la phase de développement pendant 
laquelle l'ontologie est régulièrement augmentée par de nou- 
veaux concepts, mais il faut ensuite suivre l'évolution non 
seulement des connaisances qui doivent être formalisées mais 
aussi prendre en compte les contraintes diverses liées à leur 
utilisation. Tout comme un programme, les connaissances et 
les ontologies qui les représentent doivent être maintenues, 
avec bien sur un fort impact sur tout ce qui utilise ou dépend 
de ces ontologies. 

L'évolution d'une ontologie est donc une situation fréquente 
et délicate qui demande à être très bien définie [12] et ses 
conséquences sur les instances existantes doivent être prises 
en compte. 



Nous envisageons ici à titre d'exemple deux cas simples 
(successifs) d'évolution de l'ontologie, dont nous suivrons les 
conséquences dans les différents modes de représentation. 

Modification 1: changement de domaine 

manage n'a plus pour domaine Manager mais Director. 

Modification 2: suppression de classe 

le sous-type Manager de Person est supprimé. 



4. TRADUCTION D'ONTOLOGIES DANS 
DIVERS LANGAGES : ÉTAT DE L'ART 

Le niveau le plus général de dualité de représentation 
d'une ontologie est entre son expression en génie ontologique 
et en génie logiciel (pratiquement entre l'usage d'un langage 
d'ontologies comme OWL de syntaxe RDF et un langage 
de modèles comme UML dans le cadre d'Eclipsé). Dans 
[15j est présentée notamment une correspondance entre une 
ontologie et un modèle objet. Elle se rapproche de la cor- 
respondance ORM entre modèle objet et base de données 
relationnelle déjà utilisable avec Eclipse. 

Pour ce qui est du passage dans un langage objet, il est 
souvent motivé par l'accès aux instances mais traduit aussi 
l'ontologie. ActiveRDF [21] permet d'utiliser des données 
sémantiques dans les langages orientés objet. L'accent est 
surtout mis sur les adaptateurs génériques SPARQL ou spé- 
cialisés mais les différences à surmonter au niveau de l'hérita- 
ge et de la consistance générale sont aussi évoquées. Bar- 
talos [4| propose la création automatique de classes au sens 
orienté objet pour contenir des objets correspondant aux in- 
stances ontologiques. Il souligne que les classes n'ont pas la 
prétention de couvrir toute la complexité de l'ontologie ni 
de servir pour un quelconque raisonnement. OntoJava [13] 
traduit des ontologies écrites avec Protégé et des règles en 
RuleML dans une base d'objets avec un moteur de règles. 
Kalyanpur [Î9] note d'abord la richesse sémantique de OWL 
et cerne les différences entre la logique de description et les 
langages orientés objet pour traduire le mieux possible le 
modèle ontologique en Java ; l'environnement de développe- 
ment Java a l'avantage de tracer et montrer les erreurs sur 
l'application ou l'ontologie. De plus une documentation est 
automatiquement créée. 

Quant aux travaux établissant un échange entre ontologies 
et base de données, ils sont très divers et les correspondances 
proposées sont orientées soit de la base de données vers le 
modèle ontologique lorsqu'il s'agit de rendre accessible aux 
internautes le web profond soit de l'ontologie vers une base 
de données lorsqu'il s'agit de réaliser un stockage optimisé. 

Pour traduire une base de données en une ontologie on 
utilise surtout son schéma logique ou même son schéma con- 
ceptuel [TD], pp. Des langages spécialisés comme D2RQ [^ 
expriment les correspondances générées automatiquement 
ou explicitées par l'utilisateur. L'ontologie n'est en général 
pas explicitement peuplée comme dans Virtuoso [llj où les 
requêtes du type SPARQL sont traduites en SQL. Bordiga 
[S] montre la complémentarité d'une ontologie vue en réseau 
sémantique et en base de données : cette dernière assure la 
gestion de la concurrence, la prévention et la récupération 
des erreurs. Une ontologie de domaine préexistante peut 
aussi être couplée à une base de données [17] • Dans cette 
optique, oii la correspondance n'est pas une traduction sys- 
tématique, un langage spécifique doit l'exprimer [3]. Enfin, 
[5] énonce des règles de transformation d'une ontologie vers 
une base de données : les tables ne se bornent pas à des 



triplets comme celles des entrepôts RDF mais reflètent au 
mieux les concepts et propriétés. 

5. VISION EN SYSTÈME DE TYPES 

Les ontologies et les annotations sémantiques peuvent être 
mises en parallèle avec les programmes qui sont aussi des 
systèmes formels. Avec cette vision, les concepts deviennent 
des types et la subsomption une inclusion de types. Dans ce 
contexte, les propriétés se rapprochent des fonctions et donc 
des signatures qui définissent leurs domaines et co-domaines. 

Notre ontologie exemple peut maintenant se définir par : 

Person, PhdStudent, Trainee, ComputerTrainee , 

McOiager, Researcher, Director, 

Department ... : type ; 
PhdStudent <= Person; 
Trainee <= Person; 
ComputerTrainee <= Trainee 
Manager <= Person; 
Researcher <= Manager; 
Director <= Manager; 
work : Person -> Department; 
manage : Manager -> Department; 

Le signe <= dénote l'inclusion de type. 

Les annotation sémantiques peuvent maintenant être vues 
comme des expressions dans un langage de programmation. 
Les instances deviennent des objets (disons des constantes) 
dont le type peut être au choix inféré ou déclaré. Sachant 
que les langages de programmations à typage fort permet- 
tent un meilleur contrôle des types, en générant autant de 
messages d'erreur que possible, nous préférerons déclarer le 
type des objets. 

ri : Person; 

r2 : PhdStudent; 

r3 , r4 : Manager ; 

r5, r6 : Researcher; 

r7, r8 : Director; 

vl , . . . , v8 : Department ; 

Modification 1 : manage a pour domaine Director. 
Les objets r4 et r6 sont utilisés dans les annotations 
manage (r4, v4) et manage (r6, v6). 

Or r4 et r6 ne sont pas de type Director et sont donc 
non conformes à la signature de manage. 

Modification 2 : le sous-type Manager de Person est sup- 
primé. 

En applicant les modifications proposées à notre ontologie 
exemple, nous obtenons un nouveau système de types: 

Person, PhdStudent, Trainee, ComputerTrainee, 

Researcher, Director, Department : type; 
PhdStudent <= Person; 
Trainee <= Person; 
ComputerTrainee <= Trainee 
Researcher <= Person; 
Director <= Person; 

En appliquant de façon classique un vérificateur de type 
à notre ensemble d'annotations, nous pouvons générer des 
messages d'erreur : dans la déclaration 

r3, r4 : Manager; 



NOTION 
ÉTUDIÉE 


OWL 


SYSTEME DE 
TYPES 


LANGAGE OBJET 


BASE DE DONNEES 


Taxonomie 


Classes 


Types 


Classes 


Tables 


Hiérarchisation 


Subsomption 


Sous- type 


Sous-classe 


Tables de même clé ou en- 
chaînées 


Description 
structurelle 


Propriétés 


Opérations 


Attributs 
Méthodes 


Colonnes ou 
tables de liaison 


Description 
Détaillée 


Domaine, Cible 
Restrictions sur 
propriétés 


Signatures 
définitions 


Corps des méthodes 


Contraintes(domaine, 
intégrité, référence) 
Triggers 


Lien taxonomie 
- description 


Propriétés 
définies à part 


Opérations liées 
au type 


Méthode définies 
dans les classe 
Interface 


Description intégrée au 
schéma des tables 


Polymorphisme 


union, Restric- 
tion de propriétés 


Type 

discriminant 


Redéfinition et sur- 
charge 


Contraintes sur une vue ou 
sous-table 


Modèle/ 
Instance 


Classes/ 
Individus 


Types/ Vari- 
ables de type 


Classes/ 
Objets 


Structure de table/ Lignes 
de table (instance de rela- 
tion) 


Equivalence des 
concepts 


Same 

ConceptAs 


Seulement types 
compatibles 


Nom de classe unique 


Eventuellement vue = table 


Identité des in- 
dividus 


SameAs mais 
IRI unique 


Individus lo- 
caux 


Objets locaux, per- 
sistance par ORM 


Clé primaire ou OID en 
relationnel-objet 



Table 1: Notions fondamentales 



le type (concept) Manager n'est pas déclaré et cette déc- 
laration n'est donc pas légale. Les objets r3 et r4 sont de 
plus utilisés dans : 

work(r3, v3) et manage(r4, v4). 

L'erreur de déclaration provoque donc aussi une non con- 
formité aux signatures des fonctions. 

Dans [20] . des règles de détection des inconsistances sont 
proposées pour un éditeur d'ontologies. En voyant une on- 
tologie comme un système de types, la consistance de l'ontologie 
et des annotations est testée par le traditionnel "type-checking". 

6. VISION EN LANGAGE À OBJETS 

Les classes OWL deviennent des classes (ou des interfaces 
en Java car c'est le seul moyen d'obtenir un multi-héritage 
dans ce langage). Analogue à owl:Thing, une classe Thing 
peut être définie comme base dont héritent toutes les autres; 
c'est également à ce niveau que l'on peut traiter la sérialisa- 
tion des données et le recueil de l'URL. 

Public class Thing 

{protected String objectURL ...} 

owl : SubClassOf dicte les hiérarchies de classes : 

Public class FrameEntity extends Thing {...} 
Public class Manager extends Person {...} 

On obtient ainsi facilement l'analogue de la hiérarchie simple 
de la figure 1. Pour aller plus loin, on a choisi l'incompatibili- 
té des statuts de Manager et Trainee (classes ontologiques 
disjointes). En objet, toute instance est générée par une 
classe unique et n'est donc instance que de celle-ci et de ses 
sur-classes. La disjonction de Manager et Trainee revient à 
leur interdire une sous classe commune. En utilisant le mul- 
tihéritage ou en Java la modélisation de Manager et Trainee 
par des interfaces II et 12, les notions de polymorphisme, 
surcharge et redéfinition sont alors exploitables (en Java, Il 



et 12 auront une fonction de blocage de même nom mais re- 
tournant des types différents et ceci interdira de définir une 
interface étendant à la fois II et 12). 

Une propriété P va s'associer comme champ membre à la 
classe C qu'elle a pour domaine (Thing si le domaine n'est 
pas précisé). Il n'y a pas de différence fondamentale entre 
les attributs membres qui représentent des propriétés type 
de données ou objet ni entre les attributs mono-valués ou 
multi-valués : il suffit d'employer le type (éventuellement 
polymorphe) ou la classe voulue et d'utiliser une collection 
adéquate pour les valeurs multiples. La notion d'accesseur 
(set et get) permet d'affecter une ou des valeurs à une pro- 
priété ou de lire ces valeurs. 

Public class Person extends FrameEntity 
{ protected Department work . . . 

public void setwork (Department d) {...]■ 

public Department getwork () {...} } 

Une restriction de propriété ne peut pas faire apparaître 
une sur-classe indépendante comme en OWL car, dans le 
monde de la programmation objet, les propriétés sont di- 
rectement attachées aux classes. Un procédé plus opéra- 
tionnel doit être utilisé : pour chaque propriété à restreindre 
dans une classe, un processus d'écoute (listener) surveille les 
accès au membre qu'est la propriété. Cette solution est très 
souple et permet aussi de valider ou invalider la contrainte 
dynamiquement. Elle peut s'appliquer dans notre exemple 
pour ComputerTrainee avec sa restriction someValuesFrom : 

Public class ComputerTrainee 
{ protected List studyAmong 

//le listener Test sera enregistré sur 

// les accesseurs à ce membre ...} 

Public Class Test implements PropertyChangeListener 
{ void surveillerPropertyChange 
(PropertyChangeEvent evt) 



// si aucune valeur de evt n'est Computer c'est 
// incorrect et une exception est levée } 

Modification 1 : manage a pour domaine Director. 

Les instances inconsistantes ont une valeur dans le champ 
mcmage et ne sont pas de classe Director. Pour limiter en- 
suite l'usage du membre manage à Director, il suffit de sup- 
primer (redéfinition à erreur) l'accesseur set de ce champ 
dans Manager et Researcher. 

Modification 2 : le sous-type Manager de Person est sup- 
primé. 

Les instances inconsistantes répondent Manager au mes- 
sage getClass ou, plus simplement sont dans la variable de 
classe gardant les références aux instances créées comme ci- 
dessous : 

public class Manager{ 
private static ArrayList tous = new ArrayListO; 
public Manager () 
■[tous . add (new WeakRef erence(this) ) ; } ...} 

Pour empêcher de créer désormais des instances de Mainager, 
sa méthode de création est bloquée. 

7. TRADUCTION EN BASE DE DONNÉES 

Les classes OWL correspondent généralement à la défini- 
tion de tables entités. 

Les propriétés OWL mono-valuées sont alors les champs 

de ces tables. Un cas particulier est l'identificateur clé pri- 
maire qui n'est cependant pas une référence absolue compa- 
rable à une URL Les propriétés mono-valuées vers un objet 
sont des champs avec une contrainte référence. 

CREATE TABLE Person 

(IDPerson INTEGER PRIMARY KEY, 

work INTEGER REFERENCES Department) ; 

Les autres propriétés (comme StudyAmong) donnent des 
tables associations : 

CREATE TABLE StudyAmong 
(IDTrainee INTEGER REFERENCES Trainee, 
IDDepartment INTEGER REFERENCES Department, 
PRIMARY KEY (IDTrainee, IDDepartment)) 

La traduction de sous-classes en tables séparées peut se 
faire par plusieurs méthodes. Table et sous-table peuvent 
avoir même clé ou s'enchaîner par des colonnes référentielles, 
comme ici la table Person et sa sous-table Manager : 

Table Person(IDPerson, 

SCPerson, DISManagerTraineePhdStudent , REFwork) 

Table Manager (IDManager, 
SCManager, DISReseaircherDirector , REFmanage) 

Une ligne de la table Person ne valorisant pas les colonnes 
SCPerson (référentielle) et DISManagerTraineePhdStudent 
décrit une personne sans plus de précision : 

Person (rl, , ,vl) 

Une ligne de la table Person valorisant la colonne SCPerson 
(ici à r'3) et DISManagerTraineePhdStudent (à manager) 
doit être complétée par la ligne (ici de clé r'3) de Manager : 

Person(r3, r'3, manager, v3) Manager(r'3, , ,) 



La colonne v3 référencie le département (Department) oii 
travaille la personne r3. On peut envisager qu'une per- 
sonne de la sous-classe Manager ne travaille que dans certains 
départements et l'exprimer par une restriction en OWL. 
Cette restriction s'écrira par un déclencheur sur insertion 
d'instance create trigger bef ore insert qui vérifiera le 
département référencé 

Les classes OWL intersection, union ou complémentaire ne 
sont pas définies comme tables mais plutôt comme vues. Des 
déclencheurs (triggers) de type instead of pourront faire 
une insertion dans les tables supportant les vues. Les dé- 
clencheurs traduisent aussi des axiomes exprimant des con- 
traintes sur les extensions des concepts : owl:DisjointWith 
par exemple sera assuré par un déclencheur contraignant 
l'ajout ou la modification. Les faits sont donc les lignes des 
tables : 

Person (rl, , ,vl) 

Person (r2 , r ' 2 , phdstudent , v2) PhdStudent (r ' 2) 
Person(r3,r'3,mcmager,v3) Manager(r'3, , ,) 
Person(r4,r '4,mcaiager , ) Manager (r ' 4 , , , v4) 
Person (r5 , r ' 5 , manager , v5) 

Manager (r' 5 ,r' ' 5, researcher , ) Researcher (r' ' 5) 
Person (r6 , r ' 6 , manager , ) 

Manager (r ' 6 , r ' '6, researcher, v6) Researcher (r' '6) 
Person (r7 , r ' 7 , manager , v7) 

Manager (r' 7, r' ' 7, director , ) Director (r' '7) 
Person (r8 , r ' 8 , manager , ) 

Manager (r ' 8 , r " 8 , director , v8) Director (r " 8) 

Modification 1 : manage a pour domaine Director. 
Les lignes inconsistantes (r4 et r6) valorisent REFmanage 
sans s'enchaîner à des lignes de Director : 

SELECT * from Manager where REFmanage IS NOT NULL 
and DISResearcherDirector != director 

Modification 2 : le sous-type Manager de Person est sup- 
primé. 

Les instances inconsistances (r3 et r4) sont les lignes de 
Manager avec SCManager non valué (non spécialisées) : 

SELECT * FROM Manager where SCManager IS NULL 

Pour faire évoluer la base de données, il suffit d'ajouter les 
contraintes duales des requêtes SQL précédentes (un avan- 
tage de placer des contraintes ou de garder des vues est la 
possibilité de valider ou invalider l'évolution) : 

Cl) ALTER TABLE Manager ADD CONSTRAINT 
CHECK (REFmanage IS NULL 

or DISResearcherDirector = director) 

C2) ALTER TABLE Manager ADD CONSTRAINT 
CHECK (SCManager IS NOT NULL) 

8. CONCLUSION ET PERSPECTIVES 

Les tables 1 et 2 résument les possibilités d'expression of- 
fertes pour représenter une ontologie par les divers paradig- 
mes étudiés et les comparent. OWL se distingue nettement 
sur les points suivants : 

- OWL est un langage de description des données (pro- 
priétés autonomes, identité de concepts ou d'individus) 

- OWL est utilisé pour donner une sémantique au contenu 
du Web (monde ouvert) 



CRITERE 


OWL 


SYSTEME DE 
TYPES 


LANGAGE OBJET 


BASE DE DONNEES 


Utilisation 
générale 


Langage descriptif 
Editeurs spécialisés 
Raisonneur 


Programmation 
impérative et 
typée 


Programmation 
impérative, objet, 
événementiel 


Description et stockage. 
Modules événementiels 
ou procéduraux 


Population du 
modèle 


Limitée ou séparée 
(annotation) 
Rattachée aux 
modèles parfois a 
posteriori 


Réduite : vari- 
ables déclarées 
ou non 


Toute instance est 
créée par une classe 
précise (méthode de 
création invoquée) 


Essentielle : stockage 
performant 


Étendue de 
population 


Monde ouvert 


Description fer- 
mée 


Fermée mais pro- 
priétés facultatives 
possibles 


Monde fermé 


Niveau 

d'implantation 


Tout est visible mais 
les classes définies sont 
plutôt à l'usage du 
raisonneur 


Interface, 
signature 


Spécification et corps 


Optimisations, 
Vues 


Prise en compte 
des contraintes 
et gestion de la 
cohérence 


Raisonneur logique 
(consistance, tax- 
onomie, type inféré) 


Contrôle de 
type statique ou 
dynamique. 
Compilation 


Messages invoquant 
les méthodes 
Listener 


Vérification du modèle 
(normalisation) 
Contrôle événementiel 


Règles de dé- 
duction, 
Reclassement 


Raisonneur et 
moteur logique 
d'inférence 


Programmes ex- 
plicites 


Programmes ex- 
plicites 


Vues, requêtes (bases 
déductives) 


Détection 
d'inconsistances 


Raisonneur 


Compilateur 


Compilateur, Inter- 
préteur, exceptions 


SGBD, 
intégrité 


Intégration 
Réutilisation 


Import et Merging 


Modules 


Importation 


Vues externes, ETL, 
Entrepôt de données 



Table 2: Mise en œuvre 



- OWL s'associe à un raisonneur en logique DL. 

Ces caractéristiques de OWL sont indispensables pour la 
création initiale d'une ontologie. Cependant, dans une phase 
ultérieure d'utilisation, nous avons vu que sa représentation 
par types, objets ou tables intervient fréquemment. 

- Les types objets ou tables sont clairement déclarés et 
vérifiés (alors que les classes apparaissent dispersées en OWL, 
sans véritables déclarations), les instances leur sont attachées 
et les compilateurs et SGBD sont très efficaces. 

- Les agents et les applications du Web bénéficient alors 
des aspects de programmation événementielle que sont les 
processus d'écoute (listener) en objet ou les déclencheurs 
(trigger) en base de données. 

- La modularité est très bien gérée dans le monde de la 
programmation et des types qui a fait l'objet de nombreuses 
recherches: importation, renommage, portée des identifica- 
teurs, polymorphisme et utilisation des types comme paramètres. 

Les éditeurs d'ontologies et les outils d'annotation s'effor- 
cent d'intégrer certains de ces aspects. La manipulation 
des concepts et des faits est facilitée ainsi que leur exporta- 
tion. Ce point peut être amélioré par une meilleure approche 
des diverses représentations et c'est une des perspectives de 
notre travail. 

La taille des ontologies usuelles est le plus gros problème et 
la modularité est indispensable au niveau du développement 
comme au niveau du déploiement. M. Jarrar |18) propose 
une modularisation par sujet ou par usage au niveau con- 
ceptuel. Ici encore le monde orienté objet a son influence car 
les modules sont décrits en ORM (langage graphique basé 
sur des objets et des rôles très employé pour la modélisation 



des systèmes d'information). Nous voyons ici une rencon- 
tre entre le génie ontologique et le génie logiciel que nous 
souhaitons approfondir. Enfln, au niveau du déploiement, 
une démarche usuelle 22 consiste à voir une base de con- 
naissance comme une collection de plus petites bases dis- 
posant chacune d'un raisonneur dont les résultats sont propa- 
gés pour avoir une solution globale. Une autre option est 
choisie dans ^3] oii sont construites des vues sur des classes 
et des vues sur les propriétés avec RQL et une implantation 
dans le serveur KAON ^Ôj. Nous préconisons plutôt ces so- 
lutions plus inspirées des autres représentations : modules 
en objet, vues en bases de données. 

Comme nous le voyons, les divers systèmes de représenta- 
tion des ontologies ont chacun leurs avantages, sans parler 
des questions d'efficacité lors de la conception ou lors de 
l'utilisation. Il ne s'agit donc pas de remplacer l'un par un 
autre. Par exemple, la représentation en système de types 
pourrait apporter une meilleure compréhension de la mod- 
ularité, mais ne permettrait pas dans l'état d'aborder les 
contraintes de cardinalité, courantes dans les ontologies. La 
solution pour augmenter l'expressivité des ontologies serait 
donc d'une part de concevoir un langage de description plus 
riche que les langages existants qui prendrait en compte les 
résultats d'autres de domaines, d'autre par de comprendre 
comment compiler ces descriptions pour en obtenir des im- 
plémentations efficaces en fonction des utilisations projetées. 
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